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Beschreibung 

Verfahren zur automat ischen Wiedergewinnung von Engineering- 
daten aus Anlagen 

5 

Die Erfindung betrifft ein Verfahren zur automatischen Wie- 
dergewinnung von Engineeringdaten aus Anlagen. 

Ein derartiges Automatisierungssystem kommt insbesondere im 
10 Bereich der Automatisierungstechnik zum Einsatz. Ein derarti- 
ges Automatisierungssystem besteht in der Regel aus einer 
Vielzahl von einzelnen Automatisierungsobjekten, die haufig 
eine hohe Abhangigkeit des Automat is ierungsobjekts vom je- 
weils verwendeten Engineer ingsys tern aufweisen. 

15 

Momentan gibt es zwei grundsatzliche Verfahren, die einge- 
setzt werden. Im ersten Verfahren, wird die Wiedergewinnung 
der Engineeringdaten aus der Anlage ausgeschlossen . Anderun- 
gen der Ankge sind nur uber das Engineeringwerkzeug^moglich . 
20 Damit geben die Daten im Engineeringsystem stets den aktuel- 
len Stand wieder und die Notwendigkeit des Ruckspielens der 
Information aus der Anlage entfallt. Diese Losung besitzt die 
folgenden Nachteile: 

• Starke Kopplung z wise hen Runtime und Engineering: Das 

Engineeringsystem mufi mit der Anlage ausgeliefert werden 
und auch vom Kunden extra bezahlt werden. 

• Anderungen in der Anlage konnen nicht nachvollzogen wer- 
den: — KuimuL es zu Aiiderungen in der Anlage, — beispiolsw e i se — 

durch Austausch eines Gerats, konnen diese Anderungen 
30 nicht automatisch im -Engineeringsystem nachvollzogen wer- 

den. 

• Hoher organisatorischer Auf wand : Urn die Engineeringdaten 
aktuell zu halten, mussen organisatorische Vorkehrungen 
getroffen werden, durch die sichergestellt wird, wie Ande- 

3 5 rungen in der Anlage in das Engineeringsystem eingebracht 

werden . 
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Der zweite Ansatz beruht auf einer Disassemblierung des 
Runtimecodes. Dabei wird der ausfuhrbare Code der Runtimeob- 
jekte analysiert und in die Gegenstucke des Engineering uber- 
setzt. Diese Losung besitzt die folgenden Nachteile: 
5 • Aufwendiges Verfahren: Die Analyse des Runtimecodes ist 
komplex und anfallig fur Fehler. 

• Implement ierungsabhangig : Die Implementierung der Ruck- 
ubersetzung ist stark abhangig von der Realisierung des 
Ubersetzungsvorgangs . Anderungen des Ubersetzungsvorgangs 

10 und vor allem des erzeugten Codes erzwingen die Anpassung 

der Implementierung des Ruckubersetzungsvorgangs . 

• ES- Information nicht mehr eindeutig herstellbar: Da der 
Runtimecode sich auf einer semantisch niedrigeren Ebene 
befindet als die eigentliche Engineeringinf ormation, kann 

15 nicht gewahrleistet werden, daS die Engineeringinf ormation 

sich exakt rekonstruieren lafit. 

Das der Erfindung zugrunde liegende Problem besteht darin, 
daS die in einer Anlage enthaltenen Inf ormationen automatisch 
20 in ein Engineer ingsys tern zuruckgespielt und dort wieder be- 
nutzt werden konnen, beispielsweise urn Anderungen in der An- 
lage zu projektieren. 

Diese Aufgabe wird durch das im Anspruch 1 angegebene Verfah- 
ren geldst. 

Dabei werden die Objekte des Engineering und der Runtime wer- 
den durch ein einheitliches Ubjektmodell beschxieben. Dadurch 
laSt sich die Entsprechung zwischen Engineeringob j ekten und 
3 0 Runtimeobj ekten auf Objektebene festlegen und es tritt kein 
Inf ormationsver lust durch die Abbildung auf. Zusatzlich kann 
eine direkte Kommunikation zwischen Engineering- und Runtime- 
objekten stattfinden, was bei der Realisierung des Verfahrens 
ausgenutzt werden kann. 
3 5 Der Zusammenhang zwischen einem Engineer ingobj ekt und seinem 
Runt imgegens tuck ist in Bild 1 beschrieben. Das Engineering- 
ob j ekt ESQ besitzt einen direkten Verweis, RTO Ref , auf seine 
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Runtimeentsprechung RTO. Dies ist moglich, da zum Zeitpunkt 
des Engineering die Runtimeobj ekte verfiigbar sind (oder wer- 
den) . Das Runtimeobj ekt RTO besitzt keinen direkten Verweis 
auf das dazugehorige Engineeringob j ekt . Dies ist notwendig, 
5 urn eine Trennung des Engineering- und Runt imesys terns zu er- 
moglichen. Statt des sen enthalt das Objekt RTO einen identi- 
fizierenden Bezeichner, ESO Typ ID, auf den Typ des 
Engineer ingobj ekts, ESO Typ. Damit konnen dann benotigte In- 
stanzen des ESO Typs durch das RTO erzeugt werden. 

10 

Bezogen auf ein Runtimeobj ekt RTO lauft das Verfahren zur 
Wiederherstellung der Engineeringinf ormation f olgendermaSen 
ab: 

1. Bekommt ein Runtimeobj ekt den Auftrag seine Engineeringin- 
15 formation wiederherzustellen, so wendet es sish zuerst 

dann an den Typ seines Engineer ingobj ekt s mit dem Auftrag 
eine neue Instanz eines Engineeringob j ekts zu erzeugen. 

2. Bei der neu erzeugten Instanz tragt das Runtimeobjekt ei- 
nen Verweis auf sich selbst ein und beauf tragt das neue 

2 0 Engineer ingobj ekt seine Daten (die des Runtimeobj ekts) 
auszulesen. 

3. Das neue Engineeringob j ekt liest nun die Inf ormationen aus 
dem Runtimeobjekt und tragt bei sich die entsprechende En- 
gineeringinf ormation ein. 

Im folgenden wird die Erfindung anhand der in den Figuren 
dargestellten Ausfiihrungsbeispiele n&her beschrieben und er- 
lautert . 

3 0 Es zeigen: 

ein Ubersichtsbild zur Kennzeichnung der Beziehun- 
gen zwischen Engineer ingob j ekten und Runtimeobj ek- 
ten, 

eine beispielhaf te Objektsicht einer Anlage, 
eine Veranschaulichung zum Erzeugen von Gerate- 
reprasentanten im Engineering, 



FIG 1 



3 5 FIG 2 
FIG 3 
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FIG 4 eine beispielhaf te Darstellung zur Erzeugung der 

Automatisierungsobjekte in den Geratereprasentanten 
und 

FIG 5 einen Aufbau der vorhandenen Kommunikationsbezie- 

5 hungen im Engineering. 

Das Verfahren zur Wiedergewinnung der Engineeringinf ormation 
aus der Anlage lauft in drei Schritten ab: 
• Wiederherstellung der Geratereprasentanten 
10 • Wiederherstellung der Reprasentanten der Automatisierungs- 
objekte im Engineering 
6^^^ • Wiederherstellung der Kommunikationsbeziehungen zwischen 
den Reprasentanten der Automatisierungsobjekte 
Das Verfahren wird im folgenden fur die vollstandige Wieder- 
15 gewinnung der Engineeringinf ormation beschrieben. Es laSt 

sich aber genauso zur Aktualisierung bereits bestehender En- 
gineeringinf ormation, d.h. als Deltaverfahren, nutzen. Im 
weiteren wird das gesamte Verfahren mit Upload bezeichnet. 
In Bild 2 sind exemplarisch die beteiligten Objekte aufge- 
fuhrt. Auf den zwei Geraten, RG1 und RG2 , laufen jeweils zwei 
Automatisierungsobjekte. Die Automatisierungsobjekte RAOl und 
RA02 laufen auf RG1, RA03 und RA04 auf RG2 . Kommunikations- 
verbindungen sind durch Linien symbolisiert . Insgesamt exi- 
stieren also zwei gerateinterne und zwei gerateubergreif ende 
Kommunikationsbeziehungen . 




20 



1. Wiedarhorstellxmsr der Geratereprasentanten 

Der Be g inn d e s Uploads wird aus e inem S o f tw a resystem heraus 

angestoSen. Dabei kann es sich urn ein Engineer ingsys tern oder 
ein beliebiges anderes System, das Engineeringinf ormation be- 

3 0 notigt, handeln. Ein Beispiel hierfur ist ein System zur Pa- 
rametrierung der Anlage. Der Einfachheit halber wird im fol- 
genden iiraner von einem Engineeringsystem gesprochen. 
Im ersten Schritt Werden alle Gerate aufgefordert ihre Repre- 
sentation im Engineering zu erzeugen. Dazu liefert .jedes Ge- 

3 5 rat einen Identifier des Typs seines Engineer inggegens tucks 

zurtlck. Das Engineeringsystem erzeugt dann die entsprechenden 
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Objekte und tragt bei jedem Geratereprasentanten den Verweis 
auf das konkrete Gerat ein. Mittels des Verweise liest jeder 
Geratereprasentant dann die relevanten Daten „ seines" Gerats 
aus . 

5 Bild 3 veranschaulicht das eben Beschriebene . Die Gerate der 
Anlage, hier RGl und RG2 , erhalten die Aufforderung zum 
Upload durch das Engineer ingsys tern. Sie liefern dann jeweils 
die Identifier der Typen der Engineeringreprasentanten zu- 
ruck. Das Engineer ingsys tem erzeugt fur die entsprechenden 
10 Typen die Instanzen Gl und G2 . Diese lesen dann aus den Ge- 
raten RGl und RG2 die relevanten Engineeringinf ormation aus . 

2. WiederherstQllung- der Automat islerun&sobjekte Im Ensrinee- 
ringr 

Im zweiten Schritt werden die Reprasentanten der Automatisie- 
15 rungsobjekte im Engineering erzeugt. Uber das ihm zugeordnete 
Gerat fordert jeder Geratereprasentant die Automatisierungs- 
objekte seines Gerats auf, ihre Entsprechungen im Engineering 
zu erzeugen. Dazu liefert jedes Automatisierungsobjekt den 
Identifier des Typs seines Engineeringreprasentanten zuruck. 

2 0 Im Engineer ingsys tem werden dann wieder die entsprechenden 

Objekte erzeugt und mit einem Verweis auf ihren Partner in 
der Runtimeumgebung versehen. Danach fragt jedes Automatisie- 
rungsobjekt im Engineering die relevanten Daten seines Part- 

^V^^^ ners ab. 

Das Ergebnis dieses Vorgangs ist in Bild 4 zu sehen. Der 
Reprasentant Gl fragt von dem Gerat RGl die Automatisierungs- 

objekte RAOl und RA02 ab. Dies w e rd e n dann von Gl z um Upload 

aufgefordert und liefern die Identifier der Typen von AOl und 
A02 zuruck. Mittels dieser Information werden im Engineering 

3 0 die Instanzen AOl und A02 erzeugt. Diese erhalten dann eine 

Referenz auf ihre Runtimependants RAOl und RA02 werden 
schlieSlich dem Geratereprasentanten Gl zugeordnet. Dadurch 
ist die Information uber die Geratezuordnung der Automatisie- 
rungsobjekte wieder verfugbar. Anschliefiend lesen AOl und A02 
3 5 aus RAOl und RA02 die fur das Engineering relevanten Informa- 
tionen heraus . 



QR ?9J^3133 



6 

3. Wiederherstellung der Kammunikationsbeziehungren zwischen 
don Automat isierungsobj ekten im Engineering 1 

Im letzten Schritt werden die Kommunikationsbeziehungen zwi- 
schen den Automatisierungsobj ekten wiederhergestellt . Dazu 
5 fragt jeder Geratereprasentant das ihm zugeordnete Gerat nach 
seinen Kommunikationsbeziehungen. Das Gerat liefert dann eine 
Liste mit sowohl den gerateinternen als auch gerateubergrei- 
fenden Kommunikationsbeziehungen zuruck. Ein Eintrag dieser 
Liste besteht aus Quelle und Senke der Kommunikationsbezie- 
10 hung. Quelle und Senke werden jeweils durch ein 3-Tupel aus 
dem Identifier des physikali schen Gerats, dem Identifier des 
40^^^ Automatisierungobjekts und dem Identifier des Ein- bzw. Aus- 
^^^F gangs beschrieben. 

15 Im Engineeringsystem werden die Eintrage der Liste in Verwei- 
se auf die Ein- und Ausgange der Reprasentanten der Automati- 
sierungsobj ekte umgesetzt. Dazu wird die Information aus den 
bereits erzeugten Ob j ekten (die Verweise der Engineer ing- 
reprasentanten auf ihre Runtimegegenstiicke) benutzt. An- 

2 0 schliefiend wird dann die Verbindung im Engineeringsystem auf- 

gebaut . 

Eine effiziente Realisierung dieses Schritts wird darauf ach- 
^ ten, daS die vom jeden Gerat erzeugte Liste mit Kommunika- 

J^^E tionsverbindungen nur solche enthalt, bei denen das Gerat im 
Identifier der Quelle (alternativ der Senke) auftaucht. Des 
weiteren wird ein effektives Verfahren die in den Schritten 1 
und 2 aufgebauten Beziehungen zwischen Engineer ingreprasen- 
tanten und Runtimegegenstucken zwischenspeichern, urn so den 

3 0 Suchaufwand in Schritt 3 zu minimieren. 

Bild 5 zeigt nun das Ergebnis des letzten Schritts. Gl hat 
von RG1 die Kommunikationsbeziehungen abgefragt. Dabei wurden 
die Beziehung zwischen RAOl und RA02 , RAOl und RA03 sowie 
35 zwischen RA02 und RA04 zuruckgelief ert . Die Verbindungen wer- 
den dann im Engineering umgesetzt, beispielsweise die Verbin- 
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dung zwischen RA01 und RA03 wird zu der Verbindung zwischen 
AOl und A03 . 

Sowohl die Objekte des Engineeringsystems als auch des Run- 
5 timesystems -beruhen auf dem gleichen, ausfuhrbaren Objektmo- 
dell. Durch die Verwendung des gleichen Modells ist eine di- 
rekte Interaktion auf Modellebene (Datenaustausch und Kom- 
munikation) zwischen den Engineering- und Runtimeobj ekten 
moglich. Des weiteren wird uber die definierte Zuordnung zwi- 
10 schen den Ob j ekten des Engineering und der Runtime eine ein- 
deutige Abbildung definiert, die unabhangig von der Implemen- 
tierung der Objekte ist. 

Dadurch ergeben sich fur das Verfahren folgende Vorteile: 
15 Trennung von Engineering und Runtime moglich: Anderungen mus- 
sen nicht notwendigerweise mit dem Engineer ingwerkzeug durch- 
gefuhrt. Bei Bedarf konnen die Anderungen jederzeit in das 
Engineer ingsys tern eingespielt werden. 

Einf aches* Verfahren: Durch die Festlegung des Verfahrens auf 
20 Ebene expliziter Modelle laiSt sich das Verfahren generell be- 
schreiben und wird so zuverlassiger . 

Einf ache und vollstandige Abbildung: Zwischen den Runtime- 
und Engineer ingobj ekten besteht eine fest definierte Bezie- 
hung, die ein vollstandiges Wiederherstellen der Engineering- 
information ermoglicht. 

Stabil gegen Implement ierungsandarungen : Die Implement ierung 
der Runtime- und Engineer ingobj ekte kann ausgewechselt wer- 

den, ohne daS dies EinfluS auf die Abbildung und damit dio 

Realisierung des Verfahrens hat. 
3 0 Werkzeugubergreif end: Der Uploadmechanismus kann auch durch 
andere Werkzeuge und nicht nur durch das Engineer ingsys tern 
benutzt werden. 



35 
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Patentanspruche 

1. Verfahren zur automatischen Wiedergewinnung von Engi- 
neer ingdaten aus Anlagen, bei dem die Objekte des Engineering 
und der Runtime durch ein einheitliches Objektmodell be- 
schrieben werden. 

2 . Verfahren nach Anspruch 1 , 

dadurch gekennzeichnet, 

daS eine direkte Kommunikation zwischen Engineering- und 
Runtimeobjekten vorgesehen ist. 
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Z u s anune n f a s s ung 

Verfahren zur automatischen Wiedergewinnung von Engineering- 
daten aus Anlagen 

Die Erfindung betrifft ein Verfahren zur automatischen Wie- 
dergewinnung von Engineer ingdaten aus Anlagen. Die Objekte 
des Engineering und der Runtime werden durch ein einheitli- 
ches Objektmodell beschrieben. Dadurch lafit sich die Entspre- 
chung zwischen Engineer ingobjekten und Runtimeobjekten auf 
Objektebene festlegen und es tritt kein Inf ormationsverlust 
durch die Abbildung auf. Zusatzlich kann eine direkte Kommu- 
nikation zwischen Engineering- und Runtimeobjekten stattfin- 
den, was bei der Realisierung des Verfahrens ausgenutzt wer- 
den kann. 
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